home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 751 < prev    next >
Internet Message Format  |  1996-08-06  |  2KB
  1. Path: teal.csn.net!not-for-mail
  2. From: thads@csn.net (Thad Smith)
  3. Newsgroups: comp.std.c
  4. Subject: Re: It this portable?
  5. Date: 15 Apr 1996 14:05:05 -0600
  6. Organization: T3 Systems
  7. Message-ID: <qqmcxQ9ytxmJ089yn@csn.net>
  8. References: <Dpp1tv.4Kq@ukpsshp1.serigate.philips.nl>
  9.  <4kj9gn$6rm@engnews1.Eng.Sun.COM> <4kmurb$f3a@usenet.pa.dec.com>
  10.  <Dpw78E.3GE@ukpsshp1.serigate.philips.nl>
  11. Reply-To: ThadSmith@acm.org
  12. NNTP-Posting-Host: 199.117.27.22
  13.  
  14. In article <Dpw78E.3GE@ukpsshp1.serigate.philips.nl>,
  15. baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) wrote:
  16.  
  17. Discussing the code:
  18.  
  19. >: >>  #include <stdio.h>
  20. >: >>  #include <limits.h>
  21. >: >>  int main( void )
  22. >: >>  {
  23. >: >>      printf( "%d", UINT_MAX );
  24. >: >>      return 0;
  25. >: >>  }
  26.  
  27. [Discussion deleted]
  28.  
  29. >Here is another reason why I think it is undefined. If there are holes
  30. >in the integers used by the implementation, there is nothing to say that
  31. >they must be in the same place in signed ints and unsigned ints. 
  32.  
  33. Classic ANSI C section 3.1.2.5 says "the range of nonnegative values
  34. of a signed integer type is a subrange of the corresponding unsigned
  35. integer type, and the representation of the same value in each type is
  36. the same."
  37.  
  38. The same-representation clause seems to require that significant bits
  39. of a common value in one representation not match holes in the other.
  40.  
  41. >Also is there anything to require that the holes even have to be the same size?
  42. >In other words do signed int and unsigned int even have to use the same number
  43. >of bits for data? 
  44.  
  45. No, but UINT_MAX >= INT_MAX.
  46.  
  47. (It makes a bit of a mockery of the integral conversions if
  48. >they do not.) Some time ago, somewhere else I remember seeing a discusion on
  49. >implementing C on a sign-and-magnitude architecture where for unsigned numbers
  50. >used the same format as signed ones but just ignored the sign bit. This would
  51. >make UINT_MAX < INT_MAX. 
  52.  
  53. Actually the example would make UINT_MAX == INT_MAX.
  54.  
  55. Concerning sign-and-magnitude representation for ints, that format
  56. seems to not meet the strict definition of "pure binary numeration
  57. system" given in ANSI Classic footnote 18, because the bits of 0 and 1
  58. are multiplied by NEGATIVE successive integral powers of 2 (the
  59. footnote doesn't seem to allow the negative possibility for data bits,
  60. except for the most significant bit).  Since footnotes are not part of
  61. the standard, however, I suppose we are free to accept other
  62. interpretations of a "pure binary numeration system".  
  63.  
  64. Thad
  65.